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(54) Method and apparatus for automated software module capability determination within a data 
processing system. 



(g) A method and apparatus for automated 
software module capability determination 
whereby one software module may determine 
the existence of required capabilities within a 
second software module. A capability list inter- 
face object is created, including fixed fields 
utilized to identify a plurality of required and/or 
desired software capabilities and a response 
code field for each listed capability. The capabi- 
lity list interface object is then transmitted to 
one or more servers which may include ad- 
ditional software modules. Upon receipt of a 
capability list interface object, the response 
code fields therein are automatically altered to 
indicate whether or not each listed capability Is 
supported by the recipient Thereafter, the 
capability list Interface object Is returned to the 
requesting software module (120) so that the 
existence of required capabilities may be deter- 
mined. An overall response code field is also 
provided within the capability list interface 
object in order to permit a requesting software 
module to rapidly determine if all listed required 
capabilities are supported by a selected server 
(124, 126, 128). 
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BACKGROUND OF THE INVENTION 

1 . Technical Field 

The present invention relates in general to the 
field of data processing systems and in particular to 
the field of data processing systems supporting mul- 
tiple interactive software modules. Still more particu- 
larly, the present invention relates to an improved 
method and apparatus for permitting one software 
module to determine the existence of a required ca- 
pability within a second software module. 

2. Description of the Related Art- 

Complex data processing systems are well 
known in the art today. Often such systems involve 
distributed processors located vast geographic dis- 
tances from each other; however, modern electronic 
communication permits such distributed systems to 
operate with great rapidity and efficiency. Additional- 
ly, modern state-of-the-art computer systems often 
utilize multiple software modules. By "software mod- 
ule" what is meant is multiple software applications, 
procedures, or groups of applications and procedures 
which exist within a data processing system. 

Communication between multiple software mod- 
ules is also well known in the art; however, a problem 
exists due to the continual improvement and altera- 
tion of existing software modules. It is not uncommon 
for a distributed data processing system operated by 
a single entity to include many different versions of the 
same software module or application within that sys- 
tem. Communicatian and/or cooperation between 
multiple software modules in such a system is thus 
rendered much more difficult due to the uncertainty re- 
garding the capabilities and functions available from 
a software module. 

The present method utilized to avoid problems 
which result from variation in capability of software 
modules within a data processing system requires a 
software module to access a second software module 
and determine the version number of that software 
module prior to attempting cooperation or communi- 
cation with that module. Additionally, the requesting 
software module must then possess knowledge of the 
capabilities of each version of the second software 
module in order to determine whether or not the ca- 
pabilities required by the first software module-are 
present within the version of the second software 
module which exists within the system. 

Thus, it should be obvious that a need exists for 
a method whereby multiple interactive software mod- 
ules within a data processing system may automati- 
cally determine the existence of a required capability 
within a second software module without requiring 
specific knowledge as to the capabilities of the various, 
versions of that software module. 



SUMMARY OF THE INVENTION 

It is therefore one object of the present invention 
to provide an improved data processing system. 
5 It is another object of the present invention to pro- 

vide an Improved data processing system supporting 
multiple Interactive software modules. 
It is yet another object of the present invention to pro- 
vide an improved method and apparatus for permit- 

10 ting one software module to determine the existence 
of a required capability within a second software mod- 
ule within a data processing system. 

The foregoing objects are achieved as is now de- 
scribed. The method and apparatus of the present In- 

15 vention provide automated software module capabil- 
ity determination whereby one software module may 
determine the existence of required capabilities within 
a second software module. A capability list interface 
object is created, including fixed fiends utilized to 

20 identify a plurality of required and/or desired software 
capabilities, and a response code field for each listed 
capability. The capability list Interface object is then 
transmitted to one or more servers which may include 
additional software modules. Upon receipt of a capa- 

25 bility list interface object, the response code fields 
therein are automatically altered to indicate whether 
or not each listed capability is supported by the reci- 
pient Thereafter, the capability list interface object is 
returned to the requesting software module so that the 

30 existence of required capabilities may be determined. 
An overall response code field Is also provided within 
the capability list interface object in order to permit a 
requesting software module to rapidly determine if all 
listed required capabilities are supported by a select- 

35 ed server. 

BRIEF DESCRIPTION OF THE DRAWING 

The invention, as well as a preferred mode of use, 
40 further objects and advantages thereof, will best be 
understood by reference to the following detailed de- 
scription of an illustrative embodiment when read in 
conjunction with the accompanying drawings, where- 
in: 

45 Figure 1 Is a pictorial representation of a distrib- 

uted data processing system which may be util- 
ized to implement the method and apparatus of 
the present invention; 

Figure 2 is a graphic representation of a capability 
50 list interface object which may be utilized to imple- 

ment the method and apparatus of the present in- 
vention; 

Figure 3 a logic flowchart illustrating the creation 
of a capability list Interface object by a requesting 
65 software module in accordance with the method 

and apparatus of the present invention; 
Figure 4 is a logic flowchart illustrating the alter- 
ation of a capability list interface object by a recn 
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pient software module in accordance with the 
method and apparatus of the present invention; 
Figure 5 is a logic flowchart illustrating the proc- 
essing of a returned capability list interface object 
by a requesting software module in accordance s 
with the method and apparatus of the present in- 
vention; and 

Figure 6 is a logic flowchart illustrating the proc- 
essing of a returned optional capability fist infor- 
mation object by a requesting software module in 10 
accordance with the method and apparatus of the 
present invention. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENT is 

With reference now to the figures and in particular 
with reference to Figure 1 , there is depicted a pictorial 
representation of a distributed data processing sys- 
tem 8 which may be utilized to implement the method 20 
and apparatus of the present invention. As may be 
seen, data processing system 8 may include a plural- 
ity of networks, such as Local Area Network (LAN) 10 
and 32, each of which preferably includes a plurality 
of individual computers 12 and 30, respectively. Of 25 
course, those skilled in the art will appreciate that a 
plurality of Intelligent Work Stations (IWS) coupled to 
a host processor may be utilized for each such net- 
work. 

As is common in such data processing systems, 30 
each computer may be coupled to a storage device 14 
and/or a printer/output device 16. Still referring to Fig- 
ure 1, it may be seen that distributed data processing 
system 8 also includes multiple central computer sys- 
tems, such as central computer system 18, which may 35 
be preferably coupled to Local Area Network (LAN) 1 0 
by means of communications link 22. In the depicted 
embodiment of distributed data processing system 8 
central computer 18 may be implemented utilizing an 
IBM System/370, although other computer systems, 40 
such as an IBM Application System/400 or PS/2 may 
also be utilized. In addition, a centra) computer sys- 
tem may not be necessary if one or more Local Area 
Networks are sufficient to connect all desired users 
within distributed data processing system 8. 45 

Central computer system 18 may also serve as 
remote storage for Local Area Network (LAN) 10. Sim- 
ilarly. Local Area Network (LAN) 10 may be coupled 
via communications link 24 through a subsystem con- 
trol unit/communications controller 26 and communi- so 
cations link 34 to gateway server 28. Gateway server 
28 is preferably an individual computer or Intelligent 
Work Station (IWS) which serves to link Local Area 
Network (LAN) 32 to Local Area Network (LAN) 10 
such that electronic communications between individ- 55 
uals within the network may be easily achieved. 

As discussed above with respect to Local Area 
Network (LAN) 32 and Local Area Network (LAN) 10, 



a plurality of software modules or procedures may be 
stored within storage device 20 and controlled by a 
central computer system 18, as Resource Manager or 
Library Service for the software modules thus stored. 
Of course, those skilled in the art will appreciate that 
central computer system 18 may be located a great 
geograhical distance from Local Area Network (LAN) 
10 and similarly Local Area Network (LAN) 10 may be 
located a substantial distance from Local Area Net- 
work (LAN) 32. That is, Local Area Network (LAN) 32 
may be located in California, while Local Area Net- 
work (LAN) 10 may be located in Texas and central 
computer system 1 8 may be located in New York. 

As will be appreciated upon reference to the fore- 
going, It Is often desirable for users within one portion 
of distributed data processing system 8 to be able to 
utilize software modules or procedures within another 
portion of distributed data processing system 8. For 
example, central computer system 18 may include a 
communications router software module which may 
be utilized to route communications between various 
entities located within distributed data processing 
system 8. A user within distributed data processing 
system 8 desiring to utilize the capabilities of the com- 
munications router software module will typically 
transmit a request for such utilization to central com- 
puter system 1 8. 

Those skilled in the art will appreciate that a com- 
munications router software module may have many 
different functions and capabilities. For example, one 
communications router may support the Twinaxial 
connection, Token Ring networks, Ethernet networks, 
and not support the X.25 standard. Another commu- 
nications router may support all of those connection 
functions. Thus, it should be apparent that a need ex- 
ists for a method whereby the capabilities of selected 
software modules within distributed data processing 
system 8 may be rapidly, efficiently and automatically 
determined. Further, interactive software modules 
may exist within a single computer system. Those 
skilled in the art will appreciate that communication 
and/or cooperation between two software modules 
within the same computer system may also utilize the 
method and apparatus of the present invention. 

Referring now to Figure 2, there is depicted a 
graphic representation of a capability list Interface ob- 
ject 50 which may be utilized to implement the method 
and apparatus of the present invention. As depicted 
graphically, capability list interface object 50 is a data 
structure of a form which may be readily transmitted 
between software modules within distributed data 
processing system 8 (see Figure 1). Field 52 within 
capability list Interface object 50 Is utilized, In the de- 
picted embodiment of the present invention, to specify 
the overall length in bytes of capability list interface 
object 50. Next, field 54 is utilized to identify the data 
structure as a capability list interface object. Field 56 
within capability list interface object 50 is an overall 
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Boolean response code field, which will be utilized, in 
a manner which will be explained in greater detail 
herein, to permit a software module utilizing the ca pa- 
baity list interface object to rapidly and efficiently de- 
termine whether or not a server will support all capa- 
bilities required by that software module. 

Next, capability list interface object 50 includes a 
plurality of capability list fields, each of which includes 
a length field 58. Length field 56 is utilized to specify 
the total length of a capability list field within capability 
list interface object 50. Thereafter, as illustrated, each 
capability list field includes a capability identification 
field 60. Within capability identification field 60 is listed 
an Identification of selected capabilities which are re- 
quired by the requesting software module. For exam- 
ple, specific capabilities or functions, such as "GET," 
"PUT," and "UPDATE" are examples of the type of ca- 
pability which may be listed within capability identifi- 
cation field 60. 

After listing an identification of each of a plurality 
of capabilities required by a requesting software mod- 
ule, each capability list field also Includes a Boolean 
response code field 62. Boolean response code field 
62 is utilized, in a manner which will be explained in 
greater detail below, to indicate whether or hot the 
server software module receiving capability list inter- 
face object 50 is capable of supporting a particular re- 
quested capability. Finally, each capability list field in- 
cludes a data field 64 which may be utilized to include 
various data, comment, or other information which 
may be required to further ascertain the specific ca- 
pabilities of a selected software module. 

With reference now to Figure 3, there is depicted 
a logic flowchart illustrating the creation of a capability 
list interface object by a requesting software module, 
in accordance with the method and apparatus of the 
present invention. As illustrated, the process begins 
at block 70 and thereafter passes to block 72 which 
depicts a determination of whether or not external 
support is required. By "external support" we mean, 
does the requesting software module require capabil- 
ities which are not present within that software module 
and which must be supported by another software 
module in an interactive manner? In the event exter- 
nal support is not required, the process merely Iter- 
ates until such time as a request for external support 
occurs. 

Still referring to block 72, in the event external 
support is required, the process passes to block 74. 
Block 74 illustrates a determination of what capabili- 
ties are required by the requesting software module. 
For example, the capabilities of "GET," "PUT," and 
"UPDATE" may be supported by other software mod- 
ules within the data processing system, but not sup- 
ported by the requesting software module. Next, block 
76 depicts the building of a capability list interface ob- 
ject, such as that depicted within Figure 2. Block 78 
illustrates the transmittal of this capability list interface 



object to a server or other interactive software module 
within the data processing system. Thereafter, the 
process terminates, as depicted in block 80. 

Referring now to Figure 4, there is depicted a log- 
5 ic flowchart illustrating the alteration of a capability list 
Interface object by a recipient software module In ac- 
cordance with the method and apparatus of the pres- 
ent invention. As above, the process begins at block 
90 and thereafter passes to block 92 which depicts the 
10 determination of whether or not a capability list inter- 
face object has been received. If not, the process 
merely iterates until such time as a capability list in- 
terface object is received. 

After receiving a capability list interface object the 

15 process passes to block 94, which depicts an exam- 
ination of the identity of the first requested capability 
listed within a capability list field of the capability list 
interface object (see Figure 2). Thereafter, block 96 il- 
lustrates a determination of whether or not the first re- 

20 quested capability is supported and if not, the process 
passes to block 98. Block 98 illustrates the entering 
of a "FALSE" value within the Boolean response code 
field associated with this capability. Those skilled in 
the art will appreciate that Boolean true or false values 

25 may be simply and efficiently represented by the bi- 
nary value zero, and the binary value one. 

Refenrins again to block 96 in the event the re- 
quested capability listed within the capability list inter- 
face object supported by the receiving software mod- 

30 ule, the process passes to block 100 which depicts 
the entering of a TRUE" value within the Boolean re- 
sponse code field associated with that capability. 

After entering either a "FALSE" or TRUE" value 
within the Boolean response code field associated 

35 with that capability, the process passes to block 1 02. 
Block 102 illustrates a determination of whether or not 
the capability under consideration Is the last listed ca- 
pability within the capability list interface object, and 
if not, the process passes to block 1 04. Block 1 04 de- 

40 picts the examination of the identity of the next re- 
quested capability listed within a capability list field of 
the capability list interface object and the process re- 
turns iteratively to block 96 for a determination of 
whether or not this capability is supported. 

45 Referring again to block 102, in the event the cur- 

rent listed capability under consideration Is the last 
listed capability within the capability list interface ob- 
ject, the process passes to block 106. Block 1 06 illus- 
trates a determination of whether or not all requested 

so capabilities within the capability list interface object 
are supported, and if so, the process passes to block 
108. Block 108 illustrates the entering of a TRUE" 
value within the overall Boolean response code field 
of the capability list interface object (see Figure 2). 

65 Referring again to block 1 06, in the event any re- 

quested capability listed within the capability list inter- 
face object are not supported, the process passes to 
block 110, which illustrates the entering of a "FALSE" 
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value within the overall Boolean response code field 
of the capability list interface object In either case, the 
process then passes to block 112, which illustrates 
the returning of the capability list interface object to 
the requesting software module. The process then 5 
terminates, as depicted In block 114. 

With reference now to Figure 5, there Is depicted 
a logic flowchart illustrating the processing of a re- 
turned capability list interface object by a requesting 
software module in accordance with the method and 10 
apparatus of the present invention. The process de- 
picted within Figure 5 begins at block 120 and there- 
after passes to block 122. Block 122 illustrates a de- 
termination of whether or not a capability list interface 
object has been returned from a server or other soft- is 
ware module. If not, the process merely iterates until 
such time as the capability list interface object is re- 
turned. 

After detecting the return of a capability list inter- 
face object the process passes to block 124. Block 20 
124 depicts a determination of whether or not the val- 
ue within the overall Boolean response code field of 
the received capability list interface object is "TRUE," 
indicating that the server supports all requested capa- 
bilities listed within the capability list interface object. 25 
If not, the process passes to block 126 

Block 126 depicts the displaying of an error mes- 
sage within the data processing system, indicating 
that the requested server does not support all request- 
ed capabilities, and the process then terminates, as 30 
depicted at block 1 34. 

Referring again to block 124, in the event the val- 
ue within the overall Boolean response code field is 
equal to "TRUE" the process passes to block 128. 
Block 1 28 illustrates another important feature of the 35 
present invention wherein the first software module 
may determine certain optional capabilities which 
may be required by that software module. That Is, ca- 
pabilities which are desired but not required in order 
to accomplish a specific task. Thereafter, the process 40 
passes to block 130 which illustrates the building of an 
optional capability list interface object. 

Those skilled in the art will appreciate that an op- 
tional capability list interface object may be construct- 
ed in the identical fashion to the capability list Inter- 45 
face that object depicted within Figure 2; however, the 
capabilities listed therein are considered optional and 
the absence of a support of any such capability by a 
server will not terminate the process. Thereafter, 
block 1 32 depicts the transmittal of the optional capa- so 
baity list interface object to a selected server and the 
process terminates, as depicted in block 134. 

Finally, referring to Figure 6, there is depicted a 
logic flow chart illustrating the processing of a re- 
turned optional capability list interface object by a re- 55 
questing software module in accordance with the 
method and apparatus of the present invention. 
Those skilled in the art, upon reference to the speci- 



fication contained herein, will appreciate that the alter- 
ation of an optional capability list interface object at a 
recipient software module will occur in an identical 
fashion to that depicted within Figure 4 herein. 

As above, this process begins at block 140 and 
thereafter passes to block 142, which illustrates a de- 
termination of whether or not an optional capability list 
interface object has been returned from a server. If 
not, the process merely iterates until such time as an 
optional capability list interface object is returned. 

Upon the occurrence of a return of an optional ca- 
pability list interface object from the server, the proc- 
ess passes to block 144. Block 144 depicts the exam- 
ination of the first listed optional capability within the 
optional capability list Interface object. Next, the proc- 
ess passes to block 146 which illustrates a determi- 
nation of whether the entry within the Boolean re- 
sponse code field for this optional capability is equal 
to TRUE" and if so, the process passes to block 148 
which depicts the listing of this capability for future ref- 
erence. 

Still referring to block 146, in the event the entry 
within the Boolean response code for this optional ca- 
pability is not equal to TRUE," the process passes to 
block 1 50 for a determination of whetheror not the list- 
ed optional capability is the last listed optional capa- 
bility within the optional capability list interface object 
If not, the process merely passes to block 152 for an 
examination of the next listed optional capability and 
then returns to block 146 to process that information 
in an iterative fashion. 

Referring again to block 1 50, in the event the cur- 
rent optional capability listed within the optional capa- 
bility list interface object is the last optional capability 
within that object, the process passes to block 154. 
Block 154 illustrates the continued processing of data 
by the requesting software module utilizing available 
external support, as required. Thereafter, the process 
terminates, as depicted in block 156. 

Upon reference to the foregoing those skilled in 
the art will appreciate that the Applicants herein have 
provided a novel, efficient, and automatic method 
whereby the existence of support for a particular ca- 
pability by one software module may be determined 
by a second software module without requiring ad- 
vance information regarding the known capabilities of 
various versions of software modules. In this manner, 
specific capabilities may be identified and requested 
and the optimal server or software module which sup- 
ports those capabilities may be rapidly and easily 
identified. 



Claims 

1. The method in a data processing system for per- 
mitting a first software module to automatically 
determine the existence of required capabilities 
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within a second software module, said method 
comprising the steps performed within a data 
processing system of: 

defining a capability list interface object 
within said data processing system; 5 

listing within said capability list interface 
qbject an identification of each of a plurality of ca- 
pabilities required by a first software module; 

thereafter transmitting said capability list 
interface object to a second software module; 10 

in response to a receipt of said capability 
list interface object at said second software mod- 
ule, permitting said second software module to al- 
ter said capability list Interface object to indicate 
which of said plurality of capabilities are support- 15 
ed by said second software module; and 

transmitting said altered capability list in- 
terface object to said first software module where- 
in the existence of required capabilities may be 
determined. 20 

The method In a data processing system for per- 
mitting a first software module to automatically 
determine the existence of required capabilities 
within a second software module according to 25 
Claim 1 , wherein said step of defining a capability 
list interface object within said data processing 
system further Includes the step of defining a re- 
sponse code field in association with each re- 
quired capability listed therein. 30 

The method in a data processing system for per- 
mitting a first software module to automatically 
determine the existence of required capabilities 
within a second software module according to 35 
Claim 2, wherein said step of permitting said sec- 
ond software module to alter said capability list In- 
terface object to Indicate which of said plurality of 
capabilities are supported by said second soft- 
ware module comprises the step of entering a re- 40 
sponse code into said response code field asso- 
ciated with each of said plurality of capabilities. 

The method in a data processing system for per- 
mitting a first software module to automatically 45 
determine the existence of required capabilities 
within a second software module according to 
Claim 2, wherein said step of defining a capability 
list interface object within said data processing 
system further includes the step of defining an 50 
overall response code field for all required capa- 
bilities listed therein. 

The method in a data processing system for per- 
mitting a first software module to automatically 55 
determine the existence of required capabilities 
within a second software module according to 
Claim 4, wherein said step of permitting said sec- 



ond software module to alter said capability list in- 
terface object to indicate which of said plurality of 
capabilities are supported by said second soft- 
ware module comprises the step of entering an 
overall response code into said overall response 
code field indicating all of said plurality of capa- 
bilities are supported by said second software 
module. 

6. The method in a data processing system for per- 
mitting a first software module to automatically 
determine the existence of required capabilities 
within a second software module according to 
Claim 1 , further including the step of listing within 
said capability list interface object an Identifica- 
tion of each of a plurality of capabilities consid- 
ered optional by a first software module. 

7. The method in a data processing system for per- 
mitting a first software module to automatically 
determine the existence of required capabilities 
within a second sotware module according to 
Claim 1, further including the step of generating 
an error message within said data processing 
system in response to a failure of said second 
software module to support all of said plurality of 
capabilities required by said first software mod- 
ule. 

8. A data processing system for permitting a first 
software module to automatically determine the 
existence of required capabilities within a second 
software module, said data processing system 
comprising: 

means for defining a capability list inter- 
face object within said data processing system; 

means for listing within said capability list 
interface object an identification of each of a plur- 
ality of capabilities required by a first software 
module; 

means for thereafter transmitting said ca- 
pability list interface object to a second software 
module; 

means for altering said capability list inter- 
face object to Indicate which of said plurality of ca- 
pabilities are supported by said second software 
module in response to a receipt of said capability 
list interface object at said second software mod- 
ule; and 

means for transmitting said altered capa- 
bility list interface object to said first software 
module 

9. The data processing system for permitting a first 
software module to automatically determine the 
existence of required capabilities within a second 
software module according to Claim 8, further in- 
cluding means for defining a response code field 
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ip association with each required capability listed 
within said capability list interface object 

10. The data processing system for permitting a first 
software module to automatically determine the s 
existence of required capabilities within a second 
software module according to Claim 9, wherein 
said means for altering said capability list inter- 
face object to indicate which of said plurality of ca- 
pabilities are supported by said second software 10 
module comprises means for entering a response 
code into said response code field associated 
with each of said plurality of capabilities. 
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